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The Trouble Report Evaluation and Analysis Tool (treat) is a 
system that provides Repair Service Bureau (rsb) personnel with an 
effective analysis tool for trouble reports that have been repaired 
(closed), treat consists of a set of computer-produced reports that 
can be tailored to the user's needs through the use of a simple report 
generator language. The user is supplied with approximately 50 
reports written in the report generator language and can build new 
ones or change copies of the standard ones. With the aid of a large 
collection of written documentation and the methodology supplied 
with the software, users can investigate certain problem areas and 
determine possible solutions. 

I. INTRODUCTION 

The Trouble Report Evaluation and Analysis Tool (treat) is a 
system that provides Repair Service Bureau (rsb) personnel with an 
effective analysis tool for closed trouble reports, treat consists of a 
series of computer-generated reports. The user is able to obtain reports 
either in a standard format or in a high-level report language. The 
user's guide {Bell System Practices) is extensive and contains both 
report documentation and methodology. Through proper use of the 
guide and the reports, certain problem areas may be detected and 
corrected. 

II. OVERVIEW OF TREAT FEATURES 

The objectives of this paper are to provide the reader with an 
overview of treat's features and a description of its development. The 
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remaining sections of this paper describe analyses of treat's output, 
give more details on its usage, and cover its developmental history and 
future use. 

With the use of treat, some of the primary areas of investigation 
are the following: 

(i) Common equipment troubles, e.g., disproportionally large num- 
ber of trouble reports on one switching machine. 

(ii) Not-found troubles (trouble reports where the line either tested 
okay or was found in the field to be okay), e.g., transient transmission 
noise problems. 

(Hi) Customer service problems, e.g., an abnormally large rate of 
missed appointments. 

(iv) Repair personnel productivity and performance, e.g., exception- 
ally long average repair time for outside craft. 

The treat reports are generated from a data base of closed trouble 
reports that are submitted to treat daily from the Loop Maintenance 
Operations System (lmos) or from a Bell Operating Company (boc) 
manual trouble report collection system. Typical rsbs process 100 to 
500 trouble reports a day. 

The treat analysis strategy is to use automatically generated re- 
ports to detect a problem area, then isolate the source of the problem 
through use of the requestable reports. These reports may be either 
prestructured or user defined. For this to be effective, the requestable 
reports must be easily and quickly obtainable. This was one of the 
basic design goals of treat. 

The automatic reports are set up for each rsb and sent at a 
predetermined frequency — usually daily, weekly, or monthly. Most 
daily reports employ a threshold mechanism whereby certain lines are 
printed only if the value exceeds the preset threshold. These reports 
are transmitted to the rsb by using lmos printers or teletypewriter 
terminals. 

The requestable reports are sent to the rsb or to a staff analyst only 
when requested. There are about 50 standard reports that may be 
requested by entering the report number and a few other parameters. 
Others may be constructed entirely by the requester through a high- 
level report generation language. The turnaround time to obtain the 
output can vary from a few minutes to a few hours, depending on 
performance options specified by the local companies. 

The treat reports are simple in format, being either the tabular or 
list type. The tabular type provides a matrix of counts that satisfies 
the selected criteria (Fig. 1). The list type provides selected fields from 
the trouble reports that satisfy the selected criteria (Fig. 2). The 
tabular type aids in global problem identification, whereas the list type 
permits investigation on a more detailed level. 
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Fig. 1— Cable count analysis— tabular version. 
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Fig. 2 — Cable count analysis — list version. 

III. ANALYSIS 

The bureau's trouble reports provide information useful in detecting 
areas for improvement. Some of the data items in the trouble report 
stored for analysis by treat are as follows: 
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(i) Telephone number 

(ii) Data and time reported, tested, dispatched, and cleared 
(Hi) Category of report (customer direct, customer relayed, or 
employee report, etc.) 

(iv) Class of service (business, residence, PBX, coin, etc.) 
(v) Type of report — what the customer told the repair service 
attendant, e.g., no dial tone 

(vi) Disposition — what was done to fix the trouble, e.g., repaired 
station set 

(vii) Cause — what caused the trouble, e.g., weather 
(via) Central office line equipment 
(ix) Cable and pair 

(x) Repair personnel, e.g., rsb tester or outside craft 
(xi) Elapsed time for each step in the repair process 
(xii) Miscellaneous other items. 

This ability to specify trouble report selection criteria allows the 
requester to narrow the scope of the problem and to reduce the amount 
of printout obtained. This is a crucial feature because the rsb users 
may not have high-speed printers. 

As an example of treat usage, one of the morning reports (Fig. 3) 
summarizes the trouble report activity of the previous day and accu- 
mulates the activity for the report month. The report month runs from 
the 23rd of one calendar month to the 22nd of the next. In the example 
provided, the threshold for item R is exceeded. This indicates that 
repeated reports (i.e., troubles where the customer calls back within 
30 days) are still too high, treat report number 17 (Fig. 4) shows, by 
tester, how many tested reports later had another "repeated" report. 
This example shows that tester "1" had about 16 percent (92/593) 
repeated reports, higher than the user's objective of 10 percent. A 
detailed listing of all of these reports can be requested and reviewed 
for possible improvements in the testing procedure or additional tester 
training. 

In addition to the analysis : oriented reports, treat provides a series 
of reports and interfaces for AT&T, public utility commissions, and 
other centrally developed systems. 

IV. USAGE 

treat executes on an IBM 370 compatible computer. The request- 
able reports are obtained through IMS requests that feed a batch 
reporting system (Fig. 5). The automatic reports come from a strictly 
batch system. The IBM 370 was chosen because it was the same 
machine supporting lmos. This choice also made it possible to deploy 
treat in advance of lmos since all bocs had data centers with 370 
capability. 
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Fig. 3 — Morning report. 



The treat data base consists of closed trouble reports for the most 
recent 40 days. The 40-day period was selected to provide a monthly 
data base, with enough extra days to be certain that end-of-the-month 
reports can be generated before first-of-the-month data are deleted. 
The trouble reports are entered into treat nightly from either lmos 
or from a BOC-supplied collection system. This is a batch operation in 
which trouble reports are edited and either accepted or rejected, 
certain fields are automatically scored, and data are entered into the 
data base. The 41st day's data are removed with each update. The 
data are organized by rsb, with the oldest data at the end of the files. 

All treat reports are generated either from this 40-day data base, 
known as the Cumulative Abbreviated Trouble (cat) file or from 
summary files derived from the cat file. Daily reports are generated 
after the update is made. 

In addition to the cat file, there are several auxiliary files used to 
define rsb hierarchy up to the company level (six levels), and other 
rsb parameters used to run treat. These files are updated rather 
infrequently as needed. 

The heart of the report-generating capability of treat is the report 
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Fig. 4 — Repeated report analysis for the craft person. 

compiler. This report compiler is used to generate most of the reports. 
The report compiler can generate both tabular- and list-type reports. 
The command language was designed to be easy to use at the expense 
of extremely complex reports. For example: 

TITLE Starts the report and gives a report title. 

RSB(rsb#) Selects the RSB for the report. 

DAY(dayl,day2) Selects the span of days to be included in the 
report. 

CONDITION (expr) Gives the trouble report selection criteria. 
Simple Boolean expressions are allowed, but 
not arithmetic expressions. 

SORT Sorts by fields on the trouble report. 

PRINT Gives the fields to print on a list-type report, 
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Fig. 5 — treat report generation. 

or the horizontal and vertical fields to use for 
a tabular report. 
A sample list-type report is as follows: 
TITLE (This is a sample TREAT report request) 

RSB(020) 

DAY(1,10) 

CONDITION(CAT=1&CS=04) 

SORT(RECD,TN) 

PRINT(RECD,TN,TYPE,DISP,CAUSE) 

Although there are currently about 25 commands, most reports can 
be obtained with six to eight commands. In actual practice, the 
commands used are fairly simple. 

The automatic reports are run off-hours through the report compiler 
as batch programs. The output is usually placed on a file to be 
transmitted back to the user at the rsb rather than printed at the data 
center. 

Other than an older Time Sharing Option (tso) of treat, there are 
two report request modes: 

(i) ONLINE— The report request is entered by requesting an 
Information Management System (ims) report request mask at an 
lmos on-line terminal. The mask is filled in with treat commands as 
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illustrated above and transmitted. The request is queued up and the 
actual report is prepared in a deferred batch mode, along with those 
from other requesters. Depending on the company's choice, this is 
done from a few times a day to several dozen times a day. The output 
is returned to the rsb on an lmos on-line printer. Turnaround in this 
mode varies from 10-15 minutes to a few hours depending on the boc's 
environment. 

(ii) BATCH — The report requests are gathered manually, and the 
inputs are prepared in punched-card format. The reports are generated 
in a batch mode, with the printout usually being delivered to the 
requester by mail. Fortunately, this is not a mode that is used very 
much, but was useful prior to converting to lmos. 

The report compiler runs the same way in all modes, which makes 
for an easy user transition from batch to on-line because the reports 
are identical — only the method of requesting changes. 

treat has about 50 standard reports that were designed to provide 
a boc with a basic set of reports. About 40 of these reports are 
generated by the report compiler, and are delivered as source com- 
mands. An analysis plan is also furnished to the users as a guide to 
help them in determining the order of report analysis and to aid them 
in ascertaining the actual problem. This approach allows boc personnel 
to make local changes to standard reports and also learn how to set up 
additional reports. Most bocs have set up many additional standard 
reports. In the bocs today, the majority of the reports are requested 
directly with the report compiler language rather than with the stand- 
ard prestructured reports. 

V. HISTORY 

treat had its beginning in January, 1973, as the reports portion of 
the mlr (Mechanized Line Record system) trial at New York Tele- 
phone Company. It was designed to provide some of the standard 
required reports for the rsb. Fortunately, it was early recognized that 
several reports were similar in format and could be produced by a 
simple general-purpose report compiler. These reports were the list 
type, and the first report compiler only had about eight commands (it 
now has over 25). treat, in this mlr environment, was well-accepted 
by rsb personnel, who especially liked getting reports the next day. 
There were no requestable reports as such, but the number of "stand- 
ard" automatic reports grew rapidly. This system eventually grew to 
support the 12 rsbs on the mlr system. 

In 1974, AT&T began looking for a replacement for its Mechanized 
Customer Trouble Report Analysis Program (mctrap), which was 
over ten years old, and was becoming difficult to change. There were 
three choices: 
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(i) Build a new mctrap II by using specifications prepared by Bell 
Laboratories from a Chesapeake & Potomac Telephone Company 
study. 

(ii) Expand the programs used for the mctrap II study to a working 
production system. 

(Hi) Separate treat (not called treat at the time but, rather, the 
mlr off-line system) from mlr, and offer it as a stand-alone system. 

treat was chosen because it was the only one in a production mode, 
it already had a working report compiler, and it was supported by a 
Bell Laboratories development staff committed to lmos/treat for 
years to come. The mlr department head, R. L. Martin, completed 
the decision-making process by coining the acronym "treat." 

AT&T chose The Bell Telephone Company of Pennsylvania (pa) 
as the trial company, and a trial start date of June 23, 1974 was set. It 
was decided to offer requestable reports through tso and to design a 
new set of standard reports. A task force met at pa and designed the 
first set of standard reports. Interestingly enough, these reports have 
remained virtually unchanged to this date. The major work needed in 
treat for the trial was to provide a manual trouble report interface, 
implement the 40 standard reports, add the tabular report feature to 
the report compiler, and provide a tso report requesting interface. 

treat, operating out of a Bell Laboratories data center, was put on- 
line for four trial rsbs in June, 1974. It was run for four months in this 
fashion, then it was moved to pa's data center. During this period, 
most work centered on cleaning up and changing the standard request- 
able reports. In addition, the treat User's Guide was developed by 

PA. 

treat was then installed in the Houston area of Southwestern Bell 
Telephone Company (sw) to precede the lmos installation. Although 
treat was to be run in batch mode only at sw the real test was that 
it would have to support 65 rsbs, a much larger number than before. 
This installation was completed in November 1974, and the worst fears 
were realized. Some of the treat update jobs had run times that 
appeared to increase with the square of the number of rsbs. Jobs that 
took minutes at pa and New York Telephone Company (ny) ran for 
almost two hours at sw. Otherwise the system worked well. 

The first release of treat to Western Electric Company (Issue 1) 
was in February, 1975, with some of the performance problems cor- 
rected. Issue 1 was installed at South Central Bell Telephone Company 
(so cn) and expanded to 135 rsbs (still the largest treat installation). 
South Central Bell Telephone Company personnel commented that 
"some part of treat was running 24 hours a day." Issue 2 was installed 
at sw (which had now become a trial company) in May, 1975, with 
still more performance improvements. 
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A redesign of treat was undertaken with an objective of signif- 
icantly reducing the run times. One way this was accomplished was 
through a more optimized file structure. This was to be treat, Issue 
3, nicknamed "speedy treat." "Speedy treat" was first installed at 
NY to replace the mlr version in December, 1976. First measurements 
were very encouraging. Tests were then run at sw in January, 1977, 
and the results were outstanding. "Speedy treat" met all expected 
performance objectives, and some that had not been planned. South 
Central Bell Telephone Company, which was limping along with treat 
Issue 2, quickly converted to "Speedy treat" in February, 1977, and 
promptly announced that they were so pleased with treat that they 
had no more requests for changes. 

Deployment of treat then began in earnest, and companies cut at 
a rate of one per month through 1977 and 1978. At this writing, all 
bocs are using treat and there are 32 data centers involved, making 
treat the most widely deployed centrally developed system. 

As an indicator of the acceptance of treat, over 6000 treat User's 
Guides have been sold. 

Finally, Issue 4 of treat was developed to change one of the major 
reports to reflect the business/residence/coin split of the Bell System, 
and to provide a few new features; New Jersey Bell Telephone Com- 
pany tested it in the summer of 1978. 

VI. TREATS FUTURE 

As a part of the second major version of the Automated Repair 
Service Bureau (arsb-2), the architecture and the implementation of 
treat were reexamined by Bell Laboratories. Two significant areas 
were explored. 

The first area was the user and the data system oriented require- 
ment — both current and future. A particular area of concern here was 
the degree to which Issue 4 served the needs of a vastly restructured 
corporation. 

The second area involved the internal implementation. The software 
was getting old and had been patched frequently. The global system 
design, on the other hand, was still judged to be sound. 

After the investigation of several alternatives, it was determined 
that a two-pronged approach was appropriate. The code is being 
redesigned and improved using newer software technologies. At the 
same time, we are incorporating several enhancements to the system 
to respond to the changing corporate requirements. As an example of 
these changes, all of the reports and the data bases in the next issue 
will be segmented. This will permit the user to retrieve all these reports 
collected by business, residence, public services, or network. This can 
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be done either on an individual bureau basis or on any level in the 
management hierarchy. 
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